home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0128 / 407.txt < prev    next >
Text File  |  1997-04-16  |  28KB  |  692 lines

  1. Info-Atari16 Digest         Thu, 25 Jul 91       Volume 91 : Issue 407
  2.  
  3. Today's Topics:
  4.                         Accidently formatting
  5. A Decent Debugger Interface (was Re: An idea for DC Software? (wish list))
  6.                         Can you believe this?
  7.                      Dave Baggett's .au converter
  8.        Function Proto types (was Re: Lattice C -- Single Pass?)
  9.                      Gemini and .APPs... (2 msgs)
  10.        Interesting Archiver Facts [was Re: Use Unlzh 1.72 ...]
  11.                    Internet-address wanted (2 msgs)
  12.                       Lattice C -- Single Pass?
  13.                            Lynx info wanted
  14.                            Mega STe in UK.
  15.                       Multisync Monitor question
  16.                     Re : Video tape backup system.
  17.                              supra clock
  18.                          Tape backup question
  19.  
  20. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  21. cross-posting to/from Usenet is getting closer, but still getting thrashed
  22. out.  Please send notifications about broken digests or bogus messages
  23. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  24.  
  25. Please send requests for un/subscription and other administrivia to
  26. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  27. instead of the moderators are likely to be lost or ignored.
  28.  
  29. If you want to unsubscribe, and you're receiving the digest indirectly
  30. from someplace (usually a BITNET host) that redistributes it, please
  31. contact the redistributor, not us.
  32. ----------------------------------------------------------------------
  33.  
  34. Date: 25 Jul 91 12:42:20 GMT
  35. From:
  36.  noao!ncar!elroy.jpl.nasa.gov!usc!snorkelwacker.mit.edu!ira.uka.de!fauern!faui43
  37.  .informatik.uni-erlangen.de!csbrod@arizona.edu (Claus Brod)
  38. Subject: Accidently formatting
  39. To: Info-Atari16@naucse.cse.nau.edu
  40.  
  41. carlfred@idt.unit.no (Carl-Fredrik Soerensen) writes:
  42.  
  43. >A friend of mine have an Atari 1040STE.
  44. >He has accidently formatted a floppy with some days work (he had no
  45. >backup).
  46. >I wonder if there exists any opportunities to recover the data (as
  47. >Norton Utilities etc.)
  48.  
  49. Formatting a disk means deleting the data completely. You don't have
  50. the slightest chance of recovering them unless your friend stopped the
  51. process soon enough.
  52.  
  53. ---
  54. ----------------------------------------------------------------------
  55. Claus Brod, Am Felsenkeller 2,                  Things. Take. Time.
  56. D-8772 Marktheidenfeld, Germany                 (Piet Hein)
  57. csbrod@medusa.informatik.uni-erlangen.de
  58. Claus_Brod@wue.maus.de
  59. ----------------------------------------------------------------------
  60.  
  61. ------------------------------
  62.  
  63. Date: 25 Jul 91 11:52:49 GMT
  64. From: mcsun!corton!chorus!cloche.chorus.fr!mm@uunet.uu.net (Marc Maathuis)
  65. Subject: A Decent Debugger Interface (was Re: An idea for DC Software? (wish
  66.  list))
  67. To: Info-Atari16@naucse.cse.nau.edu
  68.  
  69. In article <RALPH.91Jul18185320@orion.laas.fr>, ralph@laas.fr (Ralph P. Sobek)
  70.  writes:
  71.   | In article <1991Jul15.163633.26800@ux1.cso.uiuc.edu> timothyg@ncsa.uiuc.edu
  72.  (Timothy Gallivan) writes:
  73.   | | 4) A graphical interface to one of the PD debuggers would also be nice,
  74.   | |   something like dbxtool on Suns. One window has the source
  75.   | |   listing with an arrow pointing to the current line. Break points
  76.   | |   can be selected with the mouse, etc.
  77.   |
  78.   | That would already be decent!  But why can't we get a decent debugger
  79.   | environment (even on a Sun)?  I mean to have something under X11 as [...]
  80.  
  81. Looks like you want xxgdb, which is to gdb what dbxtool is to dbx.
  82. Take a look at your favorite ftp site (e.g. at nuri.iniria.fr in
  83. X/contrib/clients).
  84.  
  85. --
  86. Marc Maathuis                           Tel:    +33 (1) 30 64 82 57 (direct)
  87. Chorus systemes                         Fax:    +33 (1) 30 57 00 66
  88. 6, avenue Gustave Eiffel                E-mail: mm@chorus.fr
  89. F-78182 St. Quentin en Yvelines Cedex
  90.  
  91. ------------------------------
  92.  
  93. Date: Thu, 25 Jul 91 10:38:24 EDT
  94. From: poehland%phvax.dnet@smithkline.com
  95. Subject: Can you believe this?
  96. To: palmerjc%phvax.dnet@smithkline.com
  97.  
  98. The world needs to know about this.  I'm posting it to info-atari16. - BEN
  99.  
  100. ------------------------------
  101.  
  102. Date: 25 Jul 91 12:08:46 GMT
  103. From: unhd.unh.edu!oz!pyr579@uunet.uu.net (Technoid)
  104. Subject: Dave Baggett's .au converter
  105. To: Info-Atari16@naucse.cse.nau.edu
  106.  
  107. Hello,
  108.  
  109.         Yesterday I was extremely excited when I read a message by
  110. Dave Baggett speaking of the files he was plaicing in DIGISTUF.ARC and
  111. putting on atari.archive. I ftped the file and unarced to find 3 more arc's.
  112. None of them contained the .au converter to ST digitized sounds which is
  113. too bad, because that was the only thing I really wanted from the archive.
  114. Dave, if you are reading this, could you please put that file in
  115. atari.archive, thanks.
  116.  
  117. Stephan
  118.  
  119.  
  120. --
  121. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  122.   pyr579@oz.plymouth.edu      Stephan R. Cleaves      Salamanders Are Cool...
  123. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
  124.  
  125. ------------------------------
  126.  
  127. Date: 25 Jul 91 09:59:47 GMT
  128. From: mcsun!ukc!newcastle.ac.uk!catless!ndch@uunet.uu.net (Dave Halliday)
  129. Subject: Function Proto types (was Re: Lattice C -- Single Pass?)
  130. To: Info-Atari16@naucse.cse.nau.edu
  131.  
  132. In article <1991Jul24.180103.25979@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim
  133. Omura) writes:
  134. |>
  135. |>     I got my first "do nothing" program to compile and link and waddling
  136. |>through a slow program development I started to run into problems.  Then
  137. |>something occurred to me.  I compiled the sample program (WTEST.C) that
  138. |>comes with Lattice C and it compiled, linked and ran perfectly.  Then
  139. |>I moved the 'main()' from the bottom of the source code to my normal
  140. |>location just under the globals (the "top" of the program) and it failed
  141. |>to compile.
  142. |>
  143. |>     My best guess is that Lattice is a single pass compiler after all.
  144. |>I asked around before and was told it was multi-pass.  But it's not
  145. |>something that some programmers would notice.  At least not unless
  146. |>they try porting programs written by people who organize top down.
  147. |>
  148.  
  149. No, It's a multi pass compiler but ANSI compatable. You have run into
  150. ANSI function prototyping. In ANSI C the compiler checks to see if you
  151. pass the correct values to functions in a simmilar manner to Pascal, thus
  152. if the function is not declaired by the time you come to use it you get
  153. errors. I allways write my programs in two file one a header file and the
  154. other a C file. The header file in included in any file that uses the
  155. function I have defined in the C file.
  156.  
  157. Example:
  158. /* -------- FILE test.h -------- */
  159.  
  160. int addNumber(int,int);         /* Just tell the compiler about */
  161. void printString(const char*);  /* The function definitions     */
  162.  
  163. /* -------- FILE test.c -------- */
  164.  
  165. #include "test.h"               /* Tells the compiler what the  */
  166.                                 /* Function defs are.           */
  167. #include <stdio.h>
  168.  
  169. int addNumbers(int a, int b);
  170. {
  171.     return(a+b);
  172. };
  173.  
  174. void printString(const char* string)
  175. {
  176.     printf("%s\n",string);
  177. };
  178.  
  179. /* -------- FILE main.c -------- */
  180.  
  181. #include "test.h"               /* again tell the compiler of  */
  182.                                 /* the definitions.            */
  183.  
  184. void main()
  185. {
  186.    int a;
  187.    a = addNumbers(10,15);
  188.    printString("Hello I have just added some numbers");
  189. }
  190.  
  191. OK, the above don't do anything except illurstrate function prototyping.
  192. You will have to compile the two c files and then link them. For fast
  193. development I would recomend useing a make utilitly (eg, GNU make) but
  194. the link control files that Lattice provides work OK.
  195.  
  196. The other less desirable solution to your dilemer is to set the compiler
  197. into K&R and turn off function prototypeing.
  198.  
  199. Dave Halliday.
  200. ----------------------------------------------------------------------
  201. Dave      Address:  Computing Dept. Newcastle University, NE1 7RU. UK.
  202. Halliday  EMail  :  D.C.Halliday@newcastle.ac.uk
  203.           Phone  :  +44 91 222 8214            Fax :  +44 91 222 8232
  204.  
  205. ------------------------------
  206.  
  207. Date: 25 Jul 91 11:35:36 GMT
  208. From: mcsun!unido!urmel!kaa!michaels@uunet.uu.net (Michael Schwingen)
  209. Subject: Gemini and .APPs...
  210. To: Info-Atari16@naucse.cse.nau.edu
  211.  
  212. rjast1@unix.cis.pitt.edu (Robert J Anisko) writes:
  213.  
  214. >  APP files are basically the same thing as PRG files (you runthem the
  215. >same,etc).  Look at your DESKTOP.INF file, and notice that the line
  216. >with *.PRG and the line with *.APP are virtually identical...
  217. APP files are identical, and you can simply rename them. The extension .APP
  218. is usually used if the program needs or supports GDOS (which GEMINI does).
  219.  
  220. >file instead of GEMINI (very similar, but I think with a couple
  221. >options missing)...
  222. VENUS is only the Desktop part of GEMINI - the whole MUPFEL (command line
  223. interface) is missing.
  224. -------------------------------------------------------------------------------
  225. Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany
  226. michaels@messua.informatik.rwth-aachen.de
  227. PLEASE KEEP MAIL FROM OUTSIDE GERMANY SHORT-I HAVE TO PAY FOR INCOMING MAIL
  228.  
  229. ------------------------------
  230.  
  231. Date: 25 Jul 91 12:38:36 GMT
  232. From: noao!asuvax!ukma!psuvax1!psuvm!dearn!dmswwu1c!onm07@arizona.edu
  233. Subject: Gemini and .APPs...
  234. To: Info-Atari16@naucse.cse.nau.edu
  235.  
  236. In article <1991Jul24.011234.12997@ccu.umanitoba.ca>, umhagma1@ccu.umanitoba.ca
  237. (Dr. Phrancinstyne) says:
  238. >
  239. >Excuse my stupidity, but what are (and how do you use) .APP files?
  240. >That's all that Gemini comes as and it confuses me.
  241. >
  242. APP files really are the same as PRG files. Normally, GEM applications are
  243. names this way (to make sure that nobody copies them into the AUTO folder).
  244.  
  245. >Also, Gemini is only supposed to work with TOS 1.02 or greater.  I'm
  246. >really not sure what TOS version I have.  I tried using TOSVERS.PRG and
  247. >it told me that I have TOS 1.0.  It could be correct but I'm unsure.
  248. >I have a 520STfm which had an old single sided floppy built in.
  249. >
  250. >Can anyone give me info?
  251.  
  252. Simply start Gemini. It checks for the correct TOS version and tells you so,
  253. if you still have TOS 1.00.
  254.  
  255. ___________________________ cut here _____________________________________
  256. Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
  257. fast eMail: ONM07@DMSWWU1A.BITNET,    slow: jr@ms.maus.de (++49 251 77216)
  258. ____________________ correct me if I'm wrong _____________________________
  259.  
  260. ------------------------------
  261.  
  262. Date: 25 Jul 91 15:19:08 GMT
  263. From:
  264.  europa.asd.contel.com!noc.sura.net!haven.umd.edu!wam.umd.edu!dmb@uunet.uu.net
  265.  (David M. Baggett)
  266. Subject: Interesting Archiver Facts [was Re: Use Unlzh 1.72 ...]
  267. To: Info-Atari16@naucse.cse.nau.edu
  268.  
  269. In article <44749@cup.portal.com> Bryan_Jones_Woodworth@cup.portal.com writes:
  270. >I have heard ENOUGH!  I don't see why everyone has problems with LZH and
  271. >LHarc..  All you need to do is use UNLZH 1.72 and all your files will be
  272. >unlzh'd easily and painlessly!  It uses a nice GEM interface and I have
  273. >had *no* problems with it.
  274.  
  275. I have to agree with this, and I've said it before myself.  I use unlzh
  276. 1.72 by John Harris to extract on the ST, Lharc 1.20 (1.30 as of last
  277. night) by Roger Burrows to LHarchive on the ST, and Lharc 0.03 (Beta)
  278. by Y. Tagawa to extract and Lharchive on Unix machines.
  279.  
  280. I upload and download tons of stuff and I've never had a problem.  Not
  281. once.  I believe that early incompatibility problems have been solved.
  282.  
  283. A few interesting things I've found about archivers in general:
  284.  
  285.         o If you Arc an already-compressed file, Arc will fiddle around
  286.           for a while and then say "Storing", which is most likely the
  287.           correct thing to do.  HOWEVER, it seems that if Arc changes its
  288.           mind like this (from crunching to storing), the Arc file is
  289.           * strangely large *.  My recent DigiStuff posting is an example:
  290.           I Arc'ed the self-extracting LZH file alled DIGISTUF.TOS and
  291.           came up with an Arc file of about 250K.  Then I forced
  292.           "storing" by using "arc as ..." and the archive came out to
  293.           be 215K.  Perhaps Arc is storing CRC information in the first
  294.           case but not in the latter?  Still, it seems strange.
  295.           BTW, this is with Arc 6.02ST.
  296.  
  297.         o Of all the LHArchivers, Roger Burrows' seems to make the
  298.           smallest files.  The Unix LHA 0.03 (Beta) makes files that
  299.           are a tiny bit bigger (no surprise I guess), and * strangely *
  300.           the otherwise excellent Lharc 113 from Thomas Quester makes
  301.           .LZH files that are several K larger than their Burrows LHA
  302.           counterparts, at least in the several cases I've tried.  All
  303.           three lharc programs can uncompress files made with each
  304.           other, though, even though the compression factors are
  305.           different.
  306.  
  307.         o The new Zoo 2.1ST at least sometimes creates smaller files
  308.           than even Lharc.  Here are the results of a recent test I ran:
  309.  
  310.                 mrw------- 1 u           251231 update.zoo (hi)
  311.                 mrw------- 1 u           283792 update.lzh
  312.                 mrw------- 1 u           395288 update.zoo (normal)
  313.                 mrw------- 1 u           418149 update.arc
  314.                 mrw------- 1 u          1125376 update.tar
  315.  
  316.           The tar file consisted of mostly C source files and DRI .o files.
  317.           With "high compression" Zoo 2.1 achieved 78% compression.  Burrows'
  318.           Lharc 130 was close behind, but the other schemes seem much less
  319.           effective.  With "normal compression," however, Zoo gave its
  320.           typically sad performance.  Given my personal experience with
  321.           Zoo, I was actually suprised to see it do better than Arc in
  322.           this mode.
  323.  
  324.           Granted, this is only one example.  But it does show that at
  325.           least for some kinds of data, Zoo 2.1 gets compression factors
  326.           favorable to those previously achieved only by the "dreaded"
  327.           Lharc.
  328.  
  329. Just some food for thought...
  330.  
  331. Dave Baggett
  332. dmb@wam.umd.edu
  333.  
  334. ------------------------------
  335.  
  336. Date: 25 Jul 91 12:12:55 GMT
  337. From: mcsun!unido!math.fu-berlin.de!rusmv1!news@uunet.uu.net (MARCEL LUTZ)
  338. Subject: Internet-address wanted
  339. To: Info-Atari16@naucse.cse.nau.edu
  340.  
  341. Could someone please mail the Internet-address of
  342.  
  343. atari.archive
  344.  
  345. to me.
  346.  
  347. Thank you in advance,
  348.  
  349. Marcel
  350.  
  351. --
  352. Marcel Lutz
  353. IfW, Institute for Machine Tools
  354. University of Stuttgart, 7000 Stuttgart, Germany
  355. X400:  lutz@ifw.fertigungstechnik.uni-stuttgart.dbp.de
  356.  
  357. ------------------------------
  358.  
  359. Date: 25 Jul 91 14:34:15 GMT
  360. From:
  361.  noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!utgpu!watserv1!mathnew2@ariz
  362.  ona.edu (mathNOOS [mathNEWS editors])
  363. Subject: Internet-address wanted
  364. To: Info-Atari16@naucse.cse.nau.edu
  365.  
  366. In article <1991Jul25.114021.258@rusmv1.rus.uni-stuttgart.de> LZ@noc.belwue.de
  367.  (MARCEL LUTZ) writes:
  368. >Could someone please mail the Internet-address of
  369. >
  370. >atari.archive
  371. >
  372. >to me.
  373. >
  374. >Thank you in advance,
  375. >
  376. >Marcel
  377. >
  378. >--
  379. >Marcel Lutz
  380. >IfW, Institute for Machine Tools
  381. >University of Stuttgart, 7000 Stuttgart, Germany
  382.  
  383. I tried to mail this, but my mailer barfed at me.
  384.  
  385.  
  386. The address is "141.211.164.8".  I just tried it, and it connects
  387. properly to the ftp site.
  388.  
  389. --
  390. Marcel Goudeseune
  391. \mN Editor S91
  392. mathnew2@watserv1.uwaterloo.ca
  393.  
  394. ------------------------------
  395.  
  396. Date: 25 Jul 91 10:04:42 GMT
  397. From:
  398.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!wupost!zazen!doug.cae.wisc.edu!msi.umn.
  399.  edu!noc.MR.NET!uc!shamash!timbuk!marc@arizona.edu (Marc Bouron)
  400. Subject: Lattice C -- Single Pass?
  401. To: Info-Atari16@naucse.cse.nau.edu
  402.  
  403. In article <1991Jul24.180103.25979@lsuc.on.ca>, jimomura@lsuc.on.ca (Jim Omura)
  404.  writes:
  405. >
  406. >      I got my first "do nothing" program to compile and link and waddling
  407. > through a slow program development I started to run into problems.  Then
  408. > something occurred to me.  I compiled the sample program (WTEST.C) that
  409. > comes with Lattice C and it compiled, linked and ran perfectly.  Then
  410. > I moved the 'main()' from the bottom of the source code to my normal
  411. > location just under the globals (the "top" of the program) and it failed
  412. > to compile.
  413.  
  414. Moving main() to the `top' of your program means that, unless you give
  415. declarations for the functions used by main(), they will be assumed to return
  416. ints.  Now, when the functions are actually encountered, and they return
  417. something OTHER than ints, the compiler will barf.  And quite rightly so (no
  418. matter how many passes it makes).  I also write my C programs with main() at the
  419. `top', but I also religiously declare all the functions I'm going to use.  It's
  420. a good habit to get into ;-)
  421.  
  422. > [other stuff deleted]
  423.  
  424. [M][a][r][c]
  425.  
  426.  
  427. ################################################################################
  428. #                           #  marc@sequoia.cray.com           #     .   .     #
  429. #  Marc CR Bouron           #  M.Bouron@cray.co.uk     (ARPA)  #    _|\ /|_    #
  430. #  Cray Research (UK) Ltd.  #  M.Bouron@crayuk.uucp  (DOMAIN)  #   (_|_V_|_)   #
  431. #  +44 344 485971 x2208     #  M.Bouron@uk.co.cray    (JANET)  #     |   |     #
  432. #                           #  ...!ukc!crayuk!M.Bouron (UUCP)  #               #
  433. ################################################################################
  434.  
  435. ------------------------------
  436.  
  437. Date: 25 Jul 91 10:23:43 GMT
  438. From: mcsun!hp4nl!cwi.nl!martijn@uunet.uu.net (Martijn Roos Lindgreen)
  439. Subject: Lynx info wanted
  440. To: Info-Atari16@naucse.cse.nau.edu
  441.  
  442. Hi,
  443.  
  444. A couple of articles ago I saw something about the Lynx in this group.
  445. Is there another group where I can find more about the Lynx, or is this
  446. the group where Lynx-oriented articles appear?
  447.  
  448. Yesterday I bought a Lynx, and I am interested in the opinions on
  449. existing games, especially the multi-player games. Before spending
  450. money on games not worth it I'd like some feedback on what games are
  451. worth their money. At a friend's place I saw two people play Slime World,
  452. which is the main reason I bought the machine. Gauntlet looks promising
  453. as well. Any other info around ???
  454.  
  455. Thanks!
  456.  
  457. Martijn Roos Lindgreen
  458. martijn@cwi.nl
  459.  
  460. ------------------------------
  461.  
  462. Date: 25 Jul 91 09:29:43 GMT
  463. From: mcsun!ukc!newcastle.ac.uk!catless!ndch@uunet.uu.net (Dave Halliday)
  464. Subject: Mega STe in UK.
  465. To: Info-Atari16@naucse.cse.nau.edu
  466.  
  467. In article <1991Jul24.113038.24357@cs.nott.ac.uk>,
  468. cczcole@unicorn.nott.ac.uk (Marlon Cole) writes:
  469.  
  470. |>    Still none of the ads. in it are mentioning Mega STEs for sale - anyone
  471. |>in the UK got one yet, and if so, for how much?
  472. |>
  473.  
  474. There arn't any! Not even for the smaller developers. I've been waiting for one
  475. for about 2 months now and I'm a registered developer!
  476.  
  477. At least one good thing may come of it. We may not be the beta test site of the
  478. world like we were when the STe came out so hopfully many of the mega
  479. STe faults
  480. will have been fixed by the time we finally get them here.
  481.  
  482. Dave Halliday
  483. (D.C.Halliday@newcastle.ac.uk)
  484. ----------------------------------------------------------------------
  485. Dave      Address:  Computing Dept. Newcastle University, NE1 7RU. UK.
  486. Halliday  EMail  :  D.C.Halliday@newcastle.ac.uk
  487.           Phone  :  +44 91 222 8214            Fax :  +44 91 222 8232
  488.  
  489. ------------------------------
  490.  
  491. Date: 25 Jul 91 11:29:43 GMT
  492. From: munnari.oz.au!comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger
  493.  Sheppard)
  494. Subject: Multisync Monitor question
  495. To: Info-Atari16@naucse.cse.nau.edu
  496.  
  497. In article <3Rik63w164w@cellar.UUCP> revpk@cellar.UUCP (Brian 'Rev P-K' Siano)
  498.  writes:
  499. >
  500. >         I'm led to believe that, with a Multisync monitor, I'd be able to use
  501. > both monochrome and color resolutions on my ST.
  502. >
  503. >         My question is: Does it matter just what kind of Multisync monitor I
  504. > get? I've seen some 2Ds as low as two hundred dollars-- would it workl with
  505. > an Omniswitch?
  506. >
  507. > """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  508. > Brian Siano,                                Delaware Valley Skeptics
  509. > Rev. Philosopher-King of The First Church of the Divine Otis Redding
  510. > revpk@Cellar.UUCP                     "Ecrasez l'enfame!" - Voltaire
  511. > """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  512.  
  513. Get a 3D, they can save the settings in NVRAM, then there is no need
  514. to make ajustments each time you change resolutions.
  515. from what I have read from otheres, get a 3D and you won't be
  516. disappointed.
  517. I don't think that the 2D will work with the ST, the frame rate of
  518. the ST mono mode is 71.2 hz
  519. --
  520. ***  Roger W. Sheppard        *    Roger.Sheppard@bbs.actrix.gen.nz  ***
  521. ***  85 Donovan Rd          *  *   At least I don't Flicker, not     ***
  522. ***  Kapiti New Zealand..    *     like a dying light globe. !       ***
  523.  
  524. ------------------------------
  525.  
  526. Date: Thu, 25 Jul 91 18:36:21 +0200
  527. From: Z07801%BBRBFU01.BITNET@CUNYVM.CUNY.EDU
  528. Subject: Re : Video tape backup system.
  529. To: INFO-ATARI16@naucse.cse.nau.edu
  530.  
  531. Some month ago I have reply this message on Video Tape Bakcup.
  532.  
  533. >Dear prudence,
  534.  
  535. >    I have try the DVT VCR from Seymor/Radix system without success.
  536. >I must say that in Belgium we use the PAL system for the VCR. As far
  537. >as I know the system comes from USA (NTSC) and was adapted in
  538. >France (SECAM).
  539. >    I have send to the vendor some software remark, but no new release
  540. >is annonced, .... Bad news.
  541. >    More precision available on request :-]
  542.  
  543. By the way, I havn't any answer for macro instruction to capture ascii
  544. file in uniterm !
  545.  
  546. Patrick, INSTALLE
  547. V.U.B                      BITNET : Z07801@BBRBFU01.BITNET
  548. Free University Brussels   FAX    : 32 2 650 99 99
  549. Plantengenetica            Voice  : 32 2 650 97 49
  550. 69, rue des Chevaux
  551. B-1640 Rhode St Genese (BELGIUM, EC)
  552.  
  553. ⇦⇨
  554.  
  555. ------------------------------
  556.  
  557. Date: 25 Jul 91 12:11:48 GMT
  558. From: munnari.oz.au!comp.vuw.ac.nz!actrix!Roger.Sheppard@uunet.uu.net (Roger
  559.  Sheppard)
  560. Subject: supra clock
  561. To: Info-Atari16@naucse.cse.nau.edu
  562.  
  563.   Can some one help me with the Supra Clock Problem,
  564. this is the problem with the Clock Chip, Part No.
  565.  RCA CDP6818 or Motorola MC146818 draging down the battery.
  566.  
  567.   I read some where that Supra was replacing faulty Clock chips.
  568.  
  569.   But the real problem is that this clock chip uses to
  570. much power 50ua max, from the RCA data book.
  571.  
  572.   I did ring Supra to find out, but I was told that I
  573. would have to send my Host Adapter back for them to replace
  574. the Clock IC, with a Dallas one.
  575.  
  576. This was not just a plug in job, traces have to be cut, etc.
  577.  I asked them if they could give me the details,
  578. so I could do it myself, I told them that I was a competent
  579. Computer Engineer, no way and could not even give me the
  580. Dallas clock chip part No.
  581.  
  582. So is there some one that can give me the Part No.
  583. of the Dallas Clock Chip, and also if Possible some of
  584. the changes that where made to use this device.
  585.  
  586. If I get the Dallas Part No. I can possibly work out the modifications
  587. for myself, but will post the information here for otheres to carry out.
  588.  
  589. From what I can see in the Dallas data book, they make 99.9%
  590. compatible MC146818 that have a 10 year life with the
  591. built in battery, Part No. DS1287 and one with a external battery
  592. Part No. DS1285/Q with a current drain of 100 time less than
  593. the MC146818.
  594.  
  595. Note: I also found out that there software version 4.01, (latest)
  596. does not support BGM partions.
  597.  
  598. Thanks, Roger..
  599. --
  600. ***  Roger W. Sheppard        *    Roger.Sheppard@bbs.actrix.gen.nz  ***
  601. ***  85 Donovan Rd          *  *   At least I don't Flicker, not     ***
  602. ***  Kapiti New Zealand..    *     like a dying light globe. !       ***
  603.  
  604. ------------------------------
  605.  
  606. Date: Thu, 25 Jul 1991 19:46 +0200
  607. From: DRAGAN PROTIC <EPROTICD%yubgef51.bitnet@CUNYVM.CUNY.EDU>
  608. Subject: Tape backup question
  609. To: Info-Atari16@naucse.cse.nau.edu
  610.  
  611.         I have read read in the STart magazine few mo
  612. device sold in the USA which allows VCRs to be connected to an ST computer and
  613. use it (VCR) as an backup device. Here are some parts of the article, so you
  614. can make a better image what this device does...
  615.  
  616. =========================================================================
  617.  
  618.         DVT VCR, Fast and Affordable Videotape Backup System
  619.         ----------------------------------------------------
  620.  
  621.         Thanx to Seymor/Radix, you don't have to spend hours doing the
  622. "floppy-disk-shuffle" to backup your hard disk. With the SVT VCR backup system
  623. you now can save all of your hard-disk data directly to video tape.
  624.  
  625.         The DVT package contains a 12 page instruction manual, a single sided
  626. disk that includes the backup program and a few utilities, two five-foot RCA
  627. cables and a cartridge module. The module plugs into the ST's cartridge port
  628. and only needs a couple of inches of clearance from the side of the keyboard
  629. for cables to connect. These cables plug into the Video In/Out jacks on a VCR.
  630.  
  631.         The DVT backup program requires at least 760K of free RAM to run. A
  632. small portion of this is used by the program and the rest is set up as a
  633. buffer. When you back up your hard disk, files are copied into this buffer
  634. until it is full. This group of files, called a bundle, subsequently transfers
  635. to the VCR. This process repeats until the backup is complete. restoration is
  636. accomplished in similar fashion.
  637.  
  638.         Backups and restores can be acomplished in one of two ways: partition
  639. or individual file. Partition san be queued so that an entire hard disk backs
  640. up in one operation. You can backup individual files by selecting them one at
  641. a time and then sending a bundle of file(s) to tape. A bundle of files
  642. selected in this way can contain files from any folder and/or partition.
  643.  
  644.         DVT includes a verify function that checks the integrity of the tape
  645. backupa and can identify any "audible dropuot" areas in video tape.
  646.  
  647.         The test which took backing up of the 7.2Mb parition from a 40Mb hard
  648. rive took 2.4 minutes (20 seconds per megabyte). The tape lenght and the VCR
  649. speed determine the amount of data that can be fit on a video tape. According
  650. to Seymor/Radix, a common 120 minute VHS tape holds around 36Mb in standard
  651. play mode, and up to 108Mb in long play mode.
  652.  
  653.         DVT VCR costs US $99.95, and is avaiable from:
  654.  
  655.         Seymor/Radix Inc.
  656.         P.O. Box 166055
  657.         Irving, Texas 75016
  658.         (214) 255-7490
  659.  
  660. =========================================================================
  661.  
  662.         As tape streamers are quite expensive (and I'd rather buy another 80
  663. megs of HD than spending $600+ on an streamer ;), I am wondering if anyone
  664. owns/uses DVT VCR and, and if so, does he know if it is is compatible with
  665. European VCRs? As you know, we in Europe use PAL/SECAM, and US uses NTSC.
  666. Also, is Seymor/Radix still in business?
  667.  
  668.         Is there a company in Europe which produces similar device for Europian
  669. VCR standard? (Europe? Ups, I meant Germany ;))))
  670.  
  671.         Thanx,
  672.         Dalibor Lanik
  673.  
  674.         P.S. I'm asking all this because I managed to destroy ALL the data
  675. on my HD (now I'm in the process of recovering) because of the faulty DMA cable
  676. which caused damage to the DMA chip, and all FATs on my HD went to hell... NOW
  677. I know _why_ someone would need a backup device (but still, I don't have $$$ to
  678. spend for it) :(
  679.  
  680.  
  681.       eproticd@yubgdef51.bitnet <> Dalibor Lanik, using friend's account
  682.  
  683. I've seen things u people wouldn't believe. Attack ships on fire off the shore
  684. of Orion. I watched C-beams... glitter in the dark, near the Tannhauser gate.
  685. All those moments will be lost, in time... like tears... in rain. Time to die.
  686.  
  687.  
  688. ------------------------------
  689.  
  690. End of Info-Atari16 Digest
  691. ******************************
  692.